On Tue, 18 Aug 1998 23:04:19 +0200, Philippe Debar 
        <phi### [at] hotmailcom> wrote:
>* First, and as promised, 'why isn't there an official POV wish
>  list / bug fixes, with votes?' (I know the answer: (1) because
>  nobody maintain one and (2) because it could be too much stress
>  on the pov team :) ).

You forgot (3): most people don't understand that what they want is next to
impossible with the current architecture, so it doesn't do any good to know
that, say, nonlinear transforms are a popular wish.  That said, it would be
nice to have a central repository of POV patches, bug fixes, wishes, and
other POV programming information.  Twyst has told me he'll give me some
webspace if I want to put it together, but I'm debating whether I want to 
take on the work.

Along the same lines, a list of the bugfixes for each release of POV, 
including beta releases, sure would be nice.

>* Interior-Finish secession permits the usage of (inexistent)
>  finish_map. I wait with impatience for:
>  finish{ average finish_map{[...

I just wonder why image_map can't be used like any other pattern, making it
usable as a base for texture_map.
                                                                 
>* Why so much syntax difference between 2 dimensions vectors (.u,
>  .v), 3-4 dimensions vector (.x, .y, .z, .t), rgbft vectors, and
>  arrays ? (as you can see, I am very macro oriented);

You can use .x and .y with 2-d vectors as well, and I'm pretty sure you
can even use .u and .v with 3 and 4-d vectors, though it doesn't make sense
to do so.  You can also use .red, .green, .blue, .filter, and .transmit with
vectors from 2 to 4 dimensions, whether they are colors or not.  You just 
use whichever one makes the most sense for what you're doing.

>* bounded and clipped light_source;

I have to admit that this would be nice, if for nothing else than simulating  
specular reflection.  What do you think the syntax should look like, 
especially for clipping?

>* seed-driven crand and jitter;

The problem with this is that crand is also very dependent on how the rays
fall.  This means that, for all practical purposes, crand would still be
useless for animations, because moving the camera or the textured object or
any intervening or reflecting objects would change how many times crand gets
called for a particular object.

>* a pov-programing tutorial (not scenes, but pov itself);

This is a very good idea, and I've told Twyst that if I ever find any free
time, I'd consider writing one for his page.

>* special and spatial file format for image mapping - e.g. images
>  with more equally spaces points for spherical mapping;

Have you played with using a density pattern in a pigment statement yet?

Post a reply to this message